40 research outputs found
PrAIoritize: Learning to Prioritize Smart Contract Bugs and Vulnerabilities
Smart contract vulnerabilities and bugs have become a key concern for
software engineers, as they can lead to significant financial losses,
reputational damage, and legal issues. Therefore, prioritizing bug fixing for
smart contracts is critical to maintaining trust. Due to the lack of tracking
tools, prioritizing smart contract-reported bugs is done manually, which is a
tedious task, limits bug triaging, and needs specialized knowledge. Towards
this end, we propose PrAIoritize; an automated approach for predicting smart
contract bug priorities that assist software engineers in prioritizing highly
urgent bug reports. PrAIoritize consists of two main phases: 1) automatic
labeling, which involves the automatic construction of a smart contract keyword
lexicon and the automatic assignment of priority levels to unlabeled bug
reports; 2) model construction, which involves feature engineering and designs
layers of feed-forward neural networks (FFNNs) and bidirectional long
short-term memory (BiLSTM) with multi-class classification to better capture
the features of the textual descriptions of bugs and predict their priority
levels. The model then is trained using smart contract bug reports collected
from two data sources: open-source software (OSS) projects available on GitHub
and NVD vulnerability database. Our evaluation demonstrates significant
improvement over state-of-the-art baselines and commonly used pre-trained
models (e.g. BERT) for similar classification tasks, with 5.75%-35.29% increase
in F-measure, precision, and recall
An Integrated Modeling Framework for Managing the Deployment and Operation of Cloud Applications
Cloud computing can help Software as a Service (SaaS) providers to take advantage of the sheer number of cloud benefits such as, agility, continuity, cost reduction, autonomy, and easy management of resources. To reap the benefits, SaaS providers should create their applications to utilize the cloud platform capabilities. However, this is a daunting task. First, it requires a full understanding of the service offerings from different providers, and the meta-data artifacts required by each provider to configure the platform to efficiently deploy, run and manage the application. Second, it involves complex decisions that are specified by different stakeholders. Examples include, financial decisions (e.g., selecting a platform to reduces costs), architectural decisions (e.g., partition the application to maximize scalability), and operational decisions (e.g., distributing modules to insure availability and porting the application to other platforms). Finally, while each stakeholder may conduct a certain type of change to address a specific concern, the impact of a change may span multiple models and influence the decisions of several stakeholders. These factors motivate the need for: (i) a new architectural view model that focuses on service operation and reflects the cloud stakeholder perspectives, and (ii) a novel framework that facilitates providing holistic as well as partial architectural views, and generating the required platform artifacts by fragmenting the model into artifacts that can be easily modified separately.
This PhD research devises a novel architecture framework, "The 5+1 Architectural View Model", for cloud applications, in which each view corresponds to a different perspective on cloud application deployment. The architectural framework is realized as a cloud modeling framework, called "StratusML", which consists of a modeling language that uses layers to specify the cloud configuration space, and a transformation engine to generate the configuration space artifacts. The usefulness and practical applicability of StratusML to model multi-cloud and multi-tenant applications have been demonstrated though a representative domain example. Moreover, to automate the framework evolution as new concerns and cloud platforms emerge, this research work introduces also a novel schema matching technique, called "Liberate". Liberate supports the process of domain model creation, evolution, and transformations. Liberate helps solve the vendor lock-in problem by reducing the manual efforts required to map complex correspondences between cloud schemas whose domain concepts do not share linguistic similarities. The evaluation of Liberate shows its superiority in the cloud domain over existing schema matching approaches
Dissecting Smart Contract Languages: A Survey
Blockchain is a distributed ledger technology that gained popularity for
enabling the transformation of cryptocurrency among peers without mediation by
a centralized third-party authority. Smart contracts expand the applications of
blockchain technology and have played a role in its widespread adoption. Smart
contracts are immutable digital programs that are deployed on blockchains to
codify agreements between parties. Existing smart contract implementations have
faced challenges, including security vulnerabilities, leading to significant
losses and concerns. This has stimulated a wave of attempts to improve Smart
Contract Languages (SCLs) to overcome implementation challenges and ensure code
quality, producing many languages with diverse features. Scholars have made
some attempts to classify SCLs and clarify the process of selecting an SCL, but
to the best of our knowledge, no comprehensive survey of existing SCLs has been
published. Our work surpasses earlier efforts by evaluating a significantly
larger set of SCLs, in greater depth, to ease the process of SCL selection for
blockchain research and implementation. In this paper, we (1) propose a robust
framework for comparing existing SCLs, (2) analyze and discuss 36 SCLs,
addressing issues beyond those used to construct the comparison framework, and
(3) define new parameters for future research and development of SCLs. The
survey provides a guide for those who intend to select or use an SCL to
implement smart contracts, develop new SCLs, or add new extensions to the
existing SCLs
Smart Contract Upgradeability on the Ethereum Blockchain Platform: An Exploratory Study
Context: Smart contracts are computerized self-executing contracts that
contain clauses, which are enforced once certain conditions are met. Smart
contracts are immutable by design and cannot be modified once deployed, which
ensures trustlessness. Despite smart contracts' immutability benefits,
upgrading contract code is still necessary for bug fixes and potential feature
improvements. In the past few years, the smart contract community introduced
several practices for upgrading smart contracts. Upgradeable contracts are
smart contracts that exhibit these practices and are designed with
upgradeability in mind. During the upgrade process, a new smart contract
version is deployed with the desired modification, and subsequent user requests
will be forwarded to the latest version (upgraded contract). Nevertheless,
little is known about the characteristics of the upgrading practices, how
developers apply them, and how upgrading impacts contract usage.
Objectives: This paper aims to characterize smart contract upgrading patterns
and analyze their prevalence based on the deployed contracts that exhibit these
patterns. Furthermore, we intend to investigate the reasons why developers
upgrade contracts (e.g., introduce features, fix vulnerabilities) and how
upgrades affect the adoption and life span of a contract in practice.
Method: We collect deployed smart contracts metadata and source codes to
identify contracts that exhibit certain upgrade patterns (upgradeable
contracts) based on a set of policies. Then we trace smart contract versions
for each upgradable contract and identify the changes in contract versions
using similarity and vulnerabilities detection tools. Finally, we plan to
analyze the impact of upgrading on contract usage based on the number of
transactions received and the lifetime of the contract version
Exploring Security Practices in Infrastructure as Code: An Empirical Study
Cloud computing has become popular thanks to the widespread use of
Infrastructure as Code (IaC) tools, allowing the community to conveniently
manage and configure cloud infrastructure using scripts. However, the scripting
process itself does not automatically prevent practitioners from introducing
misconfigurations, vulnerabilities, or privacy risks. As a result, ensuring
security relies on practitioners understanding and the adoption of explicit
policies, guidelines, or best practices. In order to understand how
practitioners deal with this problem, in this work, we perform an empirical
study analyzing the adoption of IaC scripted security best practices. First, we
select and categorize widely recognized Terraform security practices
promulgated in the industry for popular cloud providers such as AWS, Azure, and
Google Cloud. Next, we assess the adoption of these practices by each cloud
provider, analyzing a sample of 812 open-source projects hosted on GitHub. For
that, we scan each project configuration files, looking for policy
implementation through static analysis (checkov). Additionally, we investigate
GitHub measures that might be correlated with adopting these best practices.
The category Access policy emerges as the most widely adopted in all providers,
while Encryption in rest are the most neglected policies. Regarding GitHub
measures correlated with best practice adoption, we observe a positive, strong
correlation between a repository number of stars and adopting practices in its
cloud infrastructure. Based on our findings, we provide guidelines for cloud
practitioners to limit infrastructure vulnerability and discuss further aspects
associated with policies that have yet to be extensively embraced within the
industry.Comment: 50 pages, 13 figures, 10 table
iContractBot: A chatbot for smart contracts’ specification and code generation
Pre-print (Óritrýnt handrit)Recently, Blockchain technology adoption has expanded to many application areas due to the evolution of smart contracts. However, developing smart contracts is non-trivial and challenging due to the lack of tools and expertise in this field. A promising solution to overcome this issue is to use Model-Driven Engineering (MDE), however, using models still involves a learning curve and might not be suitable for non-technical users. To tackle this challenge, chatbot or conversational interfaces can be used to assess the non-technical users to specify a smart contract in gradual and interactive manner. In this paper, we propose iContractBot, a chatbot for modeling and developing smart contracts. Moreover, we investigate how to integrate iContractBot with iContractML, a domainspecific modeling language for developing smart contracts, and instantiate intention models from the chatbot. The iContractBot framework provides a domain-specific language (DSL) based on the user intention and performs model-to-text transformation to generate the smart contract code. A smart contract use case is presented to demonstrate how iContractBot can be utilized for creating models and generating the deployment artifacts for smart contracts based on a simple conversationWe acknowledge the support of the Icelandic Centre for Research (Rannís) , [funding reference number 218202-051]
EnHMM: On the Use of Ensemble HMMs and Stack Traces to Predict the Reassignment of Bug Report Fields
Bug reports (BR) contain vital information that can help triaging teams
prioritize and assign bugs to developers who will provide the fixes. However,
studies have shown that BR fields often contain incorrect information that need
to be reassigned, which delays the bug fixing process. There exist approaches
for predicting whether a BR field should be reassigned or not. These studies
use mainly BR descriptions and traditional machine learning algorithms (SVM,
KNN, etc.). As such, they do not fully benefit from the sequential order of
information in BR data, such as function call sequences in BR stack traces,
which may be valuable for improving the prediction accuracy. In this paper, we
propose a novel approach, called EnHMM, for predicting the reassignment of BR
fields using ensemble Hidden Markov Models (HMMs), trained on stack traces.
EnHMM leverages the natural ability of HMMs to represent sequential data to
model the temporal order of function calls in BR stack traces. When applied to
Eclipse and Gnome BR repositories, EnHMM achieves an average precision, recall,
and F-measure of 54%, 76%, and 60% on Eclipse dataset and 41%, 69%, and 51% on
Gnome dataset. We also found that EnHMM improves over the best single HMM by
36% for Eclipse and 76% for Gnome. Finally, when comparing EnHMM to Im.ML.KNN,
a recent approach in the field, we found that the average F-measure score of
EnHMM improves the average F-measure of Im.ML.KNN by 6.80% and improves the
average recall of Im.ML.KNN by 36.09%. However, the average precision of EnHMM
is lower than that of Im.ML.KNN (53.93% as opposed to 56.71%).Comment: Published in Proceedings of the 28th IEEE International Conference on
Software Analysis, Evolution and Reengineering (SANER 2021), 11 pages, 7
figure
SLO-ML:A Language for Service Level Objective Modelling in Multi-cloud applications
Cloud modelling languages (CMLs) are designed to assist customers in tackling the diversity of services in the current cloud market. While many CMLs have been proposed in the literature, they lack practical support for automating the selection of services based on the specific service level objectives of a customer's application. We put forward SLO-ML, a novel and generative CML to capture service level requirements. Subsequently, SLO-ML selects the services to honour the customer's requirements and generates the deployment code appropriate to these services. We present the architectural design of SLO-ML and the associated broker that realises the deployment operations. We evaluate SLO-ML using an experimental case study with a group of researchers and developers using a real-world cloud application. We also assess SLO-ML's overheads through empirical scalability tests. We express the promises of SLO-ML in terms of gained productivity and experienced usability, and we highlight its limitations by analysing it as application requirements grow